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Abstract — During the mid stages of design development, up 
to Constellation Program (CxP) Preliminary Design Review 
(PDR), the requirements for leveraging 1-G human factors 
for optimizing ground processing of Flight Hardware were 
mature for levels - 2, 3, 4, and 5. This paper gives an 
overview of the accomplishments achieved during that time. 
The main focus of this paper will be on the CxP Ground 
Operations Project human factors engineering analysis 
process using a Human Factors Engineering Analysis Tool 
(HFEAT) for developing the level- 5 requirements effecting 
the design development of the subsystems for Ground 
Support System (GSS), and Ground Support Equipment 
(GSE). 1 2 
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1. Introduction 

Up to CxP PDR, the systems engineering requirements for 
Levels 2, 3, 4 and 5 for 1-G human factors was improving. 
The levels are defined as: Level 2 is Program, Level 3 is 
project, level 4 is project managers for elements, and level 5 
is design engineering. Elements can be Vehicle Integration 
Element (VIE), Mobile Launcher Element (MLE), or 
Launch Pad Element (LPE). 

Concerning this the CxP Ground Operations Projects level 3 
documents pointed to the level 2 CxP Human Systems 
Integration Requirements (HSIR) document for designing 
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flight hardware for ground processing, or for designing 
ground hardware for flight crew activities; or to the NASA 
STD 5005 for the GSE used in ground processing. The 
HSIR had specific requirements and verifications, but the 
NASA STD 5005 human factors section pointed the FAA 
HFDS. The FAA HFDS has 15 chapters, and within each 
chapter there are many standards. The level 4 requirements 
documents were for each of the GOP Elements, such as 
Mobile Launcher Element, Vertical Integration Element, etc. 
And the requirement flow from Level 3 to Level 4 did not 
add more definition to the FAA HFDS human factors 
requirements. Thus it was Level 5, Design Engineering’s 
responsibility to define the human factors requirements from 
the FAA HFDS for each CxP GOP subsystem. This great 
task was efficiently and effectively accomplished by 
developing and using a Human Factors Engineering 
Analysis tool. 


2. Human Factors Requirements & Process 

Per KDP P-2713 Rev. B, A Human Factors Engineering 
Analysis (HFEA) was performed for all CxP GOP 
Subsystems. The analysis was performed by qualified 
Human Factors Engineers using an approved Human Factors 
Engineering Analysis Tool. The analysis included a 
selection of applicable Federal Aviation Administration 
Human Factors Design Standards (FAA HFDS), and a 
selection of L3 Systems Requirements Document gap human 
factors requirements for Tool Clearances, Lifting Limits, 
Connector Miss-mate, and Personal Protection Equipment 
(PPE). 


3. Sub-Systems Analysis Using HFEA Tool 

For the CxP GOP there were over 30 subsystems that were 
given a human factors engineering analysis. Examples of 
these subsystems are: Crew Access Arm, Handling and 
Access, Umbilicals, etc. See figures 1, 2, and 3. 
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Figure 1 ML Crew Access Arm for Capsule 



Figure 2 VIE Handling and Access & ML Umbilical for 
Capsule 



Figure 3 VIE Handling and Access for Capsule 

As the designs were evolving, the HFEA was updated during 
the design review stages, and when changes to design led to 
any human factors issues. This involved review of the 
subsystems documentation, attending the (SDRP) System 
Design Review Process meetings, splinter meetings with the 
Lead Design Engineers (LDE) and systems engineers (SE). 
An initial kick off meeting is set with the LDE at the 30% 
DR. This is to introduce to the LDE, the HFEA process, 
what is their expected gain from the HFEA to their 
subsystem, and to point out any human factors issues as 
early as possible. This type of kickoff analysis is similar to 
what took place during the pilot study [3]. 

4. HFEA Tool and Process 

The HFEA analysis begins at the Subsystem 60% and is 
updated at each of the Subsystem 90% Design Review, and 


100% Design Release. The analysis was performed by 
qualified Human Factors Engineers using an approved 
HFEA Tool. During the analysis, the FAA requirements and 
Systems Requirements Document (SRD) gap requirements 
were reviewed and applied to each individual Subsystem 
where applicable. These requirements and standards are 
summarized in a HFEA Report. Information in the Report 
includes; which HFE prepared the report and their 
organization, and who concurred the report, the SEs name 
and concurrence, and the LDE’s name. Once the standards 
are selected from each chapter of the FAA HFDS they are 
summarized in a HFEA Report. That report is effectively a 
specific set of human factors requirements for a specific 
subsystem. 

Within the HFEA Tool, there are several tabs to complete 
the HFEA for a specific subsystem. And within each tab 
several fields to complete. Figure- 1 is a snapshot of the tool 
showing the tabs at the bottom and the fields to complete 
within one tab. The tab shown in Figure- 1 is the FAA 
chapter “Designing Equipment for Maintenance”. Starting 
from left to right is the sequence of completing the HFE 
analysis. From the first left tab there is the subsystem data. 
This data is; the subsystem name, the subsystem 
abbreviation, the lead designers name, the systems engineers 
name, the section heading, and the elements affected (MLE, 
LPE, VIE, etc.) In the tool, most of this input information is 
provided and the HFE simply just needs to select the 
subsystem. And the rest of the information loads up 
automatically. The next tap is the human interface. This tab 
describes all of the human interface areas. Once all of the 
human interfaces have been determined by understand the 
human activities, for all operations; Assembly, Installation, 
Nominal Use, Inspection, Maintenance, Off-Nominal use, 
Emergency use, Disassembly, and Disposal, then the HFE 
can proceed to the following tabs, which are basically the 
FAA HFDS chapters (General, Automation, Designing 
Equipment for Maintenance, Displays and Printers, Controls 
and visual indicators, Alarms audio and voice. Computer 
human interface, Input devices. Workplace design. System 
security. Personnel safety. Environment, Anthropometry and 
biomechanics, and User documentation). There is also a tab 
for any extra requirements (gap) dictated by the program or 
project, and there is a OSHA tab that includes the human 
factors OSHA type requirements. 
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5. Requirement Examples from HFEA 

Figure 1 shows three requirements that were generated in the 
“Designing Equipment for Maintenance section”. The 
following will explain all three of these by explaining each 
column input. Before describing the inputs for each column, 
the column inputs are defined as: Human/System Interfaces, 
Issues, Requirement Source (mostly FAA), Requirement 
Section Title, Requirements Sub-Section Title, Requirement 
[R], Conditions [C], Possible Consequences [PC], 
Processing Phase (PP); (Assembly/Installation, Nominal 
Use, Inspection, Maintenance, Off-Nominal Use, 

Emergency Use and Disassembly/Disposal), Requirement 
Satisfied, Primary Verification (Inspection, Analysis, 
Demonstration, Test), Risk Priority Rank Consequence, Risk 
Priority Rank Likelihood (RPRL). Risk Priority Rank 
Product, Why Non-Compliant, Potential Recommendations, 
and Notes. 

Now for the three requirement examples provided in figure- 
1, the three Human/System Interfaces from top to bottom 
are: 

• CAA actuation motor, 


rocket assembly, inspection, etc. These interfaces were 
previously uploaded in the HFEA in the 2 nd Tab by the HFE. 
Also keep in mind, although this example describes the first 
three requirements in the tool at the same time, in reality the 
HFE only develops one requirement at a time. 

The next column to complete after the Human/System 
Interfaces for these three requirements is the “Issues” 
column. The issues for these three human interfaces in order 
are; 

• “Is there access for actuator motor maintenance?” 

• Interchangeability/non-interchangeability, 

• and “Is there access for environmental chamber 
maintenance and servicing?”. 

These interfaces were determined by The FAA requirement 
section title, which is of course Designing Equipment for 
Maintenance. 

The Subsection titles for these three issues were; 



Figure 4 HFEA Tool showing the three requirement examples in the "‘Designing Equipment for Maintenance” tab 


• CAA Blast Door Actuation Cylinder, 

• and Environmental Chamber ceiling maintenance 
access. 

These human interfaces were previously determined by 
understanding all of the human activities through 
conversations with LDE and operators in relation to this 
subsystem. The activities include all launch processing 
activities: nominal, off nominal, emergency, maintenance. 


• 4. 3.4. 1.1 Complete visual and physical access., 

• 4.3.2 Interchangeability, non-interchangeability, 

• and 4. 1.4.1 ease of servicing. The requirements for 
these subsections were: 
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For the first issue; Equipment shall be positioned so that the 
maintainer has complete visual and physical access to all 
parts of the equipment on which maintenance is performed; 


this includes access openings, adjustment points, test points, 
cables, connectors, labels, and mounting fasteners. 

Second Issue; Units of equipment may be interchangeable 
physically, functionally, or both. This section contains rules 
that might be summarized in the general statements that if 
two units of equipment are interchangeable functionally, 
they will also be interchangeable physically; if they are not 
interchangeable functionally, they will not be 
interchangeable physically. 



And Third Issue; Equipment shall be designed so that it can 
be serviced in its installed position. 

The three possible consequences are for the three above 
issues are; 


Figure 5 CAA Mechanisms, Actuator Motor “shown in 
circle” 


• Delay, 

• Delay or damage, 

• Delay. 

All three of these requirements had the same processing 
phase. 

For the three issues the processing phase were; 

1 . Assembly/Installation 

2. Inspection 

3. Maintenance, and Disassembly/Disposal. 



Figure 6 CAA Actuator Motor and mechanisms 


All three of these were found compliant during inspection of 
the design drawings. And the Risk priority rank products 
were; 6, 6, and 2. There was one note for the first issue, that 
note was, ‘This requirement refers to an Actuation System 
Component that was moved to an open and more accessible 
location at the back of the Crew Access Level of the ML 
Tower.” 

These were just three HFEA requirements derived out of 
one chapter of the FAA HFDS. For the complete HFEA 
requirements for the subsystem, all standards from FAA are 
considered and the applicable standards become HFEA 
requirements for that GOP Subsystem. See figure 5 and 6 for 
example of CAA actuator motor maintenance access. 


Once all of the tabs are completed, then a PDF report can be 
generated using the “Make Report” tab. The report sorts out 
the requirements putting the non-compliant requirements at 
the top. All of the data determined during the HFEA in each 
tab is given in the report. This same report can be used by 
the HFE during the next stages of design development to 
ensure that the design reflects the human factors concerns 
that were determined in the HFEA. See figure-2 for a 
snapshot of the first page of the HFEA Report for CAA. 



Figure 7 Snapshot of CAA HFEA Requirements Report 
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6. Lessons & Future Plans 

This section gives lessons and future plans from the future 
plans from the “1-G Human Factors for Optimal Processing 
and Operability of Constellation Ground Systems” paper 
See [2], and from the current effort. All of these new lessons 
will be documented into the NASA Integrated Lessons 
Learned system. http://nen.nasa.gov/portal/site/llis/LL/ 

Design Engineering 

(1) Lesson: NESC pointed out several mishap lessons 
learned, that helped improve the ITFEAs, and the 
Subsystem designs. Future plan : Continue and elevate 
this process and collaboration with NESC. 

(2) Lesson : The human factors engineering tool , analysis, 
and report, proved to be an efficient and effective 
means to develop HFEA for the 60% and 90% and 
100% design packages . Future Plans : Continue to use 
and improve the process and tool. 

(3) Lesson : It was effective to include the HFAE tool and 
process in the GOP L3 Systems Engineering 
Management Plan (SEMP). Future Plans : Insure that 
the factors assessment process and tool is included in 
the L3, L4 and L5 SEMPs. 

(4) Lesson : Human Factors Engineer - Human interfaces 
and ergonomics was included into the KSC KDP-P- 
2713 Technical Review Process. Future Plans : Ensure 
that human factors is included in the KSC Technical 
Review Process for future Programs/Projects at KSC. 

(5) Lesson : NASA-STD-5005C was accepted by the CxP, 
and the FAA Human Factors Design Standard was 
incorporated into the human factors engineering tool. 
Future Plans : Collaborate with FAA for further 
development and applications of the HFEA Tool and 
Process. 

(6) Future Plans : Make use of human factors principles 
and analysis during the ground processing activities to 
prepare flight hardware for the CxP test flights. 

(7) Future Plans: Continue to prove the usefulness of 
human factors so that it will be commonly accepted 
into the work break down structure at KSC. 

(8) Future Plans: Improve the HFEAT by incorporating 
into the tool; design solution lessons learned from KSC 
Engineering use of HFEAT, NASA programs, 
industry, etc. 

(9) Future Plans : Employ the human factors systems 
engineering processes and lessons learned from Ares-I 
to Heavy Lift Vehicle (previously Ares-V). 


(10) Lesson Learned : The NASA CxP program level human 

factors requirements document HSIR greatly promoted 
better human factors Systems Engineering and 
Integration. This improved the integration between 
ground systems, launch vehicle, and crewed vehicle 
designs for ground processing. Current and Future 
Plans : Flight Hardware ground processing 

requirements and GSE requirements are currently 
making their way into NASA Standard 3001 volumes 
two and three. Combining the Human Factors (HF) 
standards needs for; crewed vehicle, launch vehicle, 
and ground processing of these vehicles, in the Level 1 
NASA STD 3001, promotes integration of NASA HF 
and improvements to design, SE&I processes and other 
methodologies, to all NASA programs. Additionally, 
including launch processing into the NASA STD 3001 
and applying these requirements to programs, gives us 
the opportunity to capture the lessons learned from 
those programs back into a one stop shop NASA 
human factors standard - NASA STD 3001. Much like 
the requirements and standards for flight crew have 
improved over the years in the NASA STD 3000, the 
standards and requirements for ground processing can 
be monitored and improved through the use of a single 
standard, NASA STD 3001. Since NASA STD 3001 is 
specifically a human factors document and also a Level 
1 document, this is a much better option than to house 
the ground human factors requirements in the NASA- 
STD-5005, 512-SM, L3 GS-SRDs,or revise the GS- 
HFRD. See [7] 

(11) Lesson: Early collaboration and planning between the 
flight and ground hardware designers for human 
factors engineering analysis (HFEA) is necessary. And 
having a dedicated team of HFE was very effective in 
defining and improving the HFEA process. Future 
Plans : Employ qualified human factors person/s on 
each Subsystem team from the beginning of the 
Project. Having a Human Factors engineer as part of 
the design team would help the team to develop design 
solutions to comply with any requirements at the early 
stages, and would help the HF engineer do a thorough 
evaluation of the subsystems during their development. 

(12) Lesson: Developing individual HFEA reports with the 
LDEs and SEs on their subsystem was very effective in 
bringing human factors awareness to the LDE/SEs. 

(13) Lesson : Originally the HFEA Tool was intended to be 
used by systems design engineers, and reviewed by 
human factors engineers [4]. But the process evolved 
and improved where the human factors engineers were 
involved with the design teams mostly through the 
LDEs and SEs. Some HFEA involved the human 
factors engineer to be included and attend the 
Subsystem team meetings. Future Plans : It was 
realized by attending the subsystems design team 
meetings, there would have been a better relationship 
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with the design teams and the HFEA would have been 
more effective. This approach is more feasible now 
that there is a HFEA Tool, and process. 

(14) Have a kickoff human factors meeting with the SE and 
LDE earlier in the design process at 30% so they can 
get an understanding of the HF requirements, and 
processes. Since there is limited design information at 
the 30% review, the initial HFEA should be done a few 
weeks after the 60% review where most of the human 
factors questions can be addressed and tracked at the 
60%, still leaving enough time for the designers to 
make improvements from 60% to 90%. 

(15) Lesson : Off-base human factor support personnel was 
not the best approach for providing human factors 
expertise. The HFEA Tool is a great help and 
facilitates doing the assessment. It would have been 
very difficult to perform this sophisticated analysis 
without this tool. 

(16) Lesson and Future Plans : Following the 100% HFEA, 
there should be a Human Factors requirements 
verification done by an independent auditor (HF 
person) along with Safety after the subsystems are 
installed and operating. This will verify that the “as 
built” matches the “as designed” and that all of the HF 
requirements in the HFEA have been satisfied. The 
HFEA report generated for each subsystem can be used 
as a verification checklist. There should be something 
to trigger an audit. 

(17) Lesson : When reviewing the HFEA report, the concise 
compliance notes in the notes sections of the HFEAT 
worked well. But when considering a process activity, 
it was difficult to determine the requirement 
compliance through the two dimensional drawings, or 
documents. Human activities are 3D, thus 2D 
drawings can be misleading. Future Plans : Infuse; 3D 
static models, 3D motion models, motion capture 
mockups, physical mockups, which include the human 
and the HF areas of concern into the design process. 
Also, include these into the HFEA report. Another 
solution is to improve the 2D models so they better 
capture and broadcast the HF concerns. Pro E Product 
used in Design Engineering will have capability for 
including human in 3D models generated by CAD 
models. 

(18) Lesson : The HFEAT report is basically a tailored 
requirements document for each subsystem, which the 
LDE agreed to the requirements in the HFEAT report. 
In the notes section the compliance is described. Also 
in the notes section, at early reviews, the non- 
compliances with a human factors design solution can 
be recorded so it can be met at before the next or final 
review. Additionally the LDE could provide comments 
to the HFE to be added into the notes section, pointing 


to the drawings that indicate how the FAA 
requirements will be met. 

(19) Lesson : The tool worked extremely well and was 
developed with very little funding. During this “pilot” 
use of the tool areas for improvement were discovered. 
Future Plans : There were some areas of the tool that 
are inflexible and need improvement: Deletino of rows 
or columns, requirement section drop down list, 
OSHA/HF section, columns for closure notes and for 
objective evidence for requirement compliance. 

(20) Lesson : The tool was created in excel spreadsheet with 
macros, and is only used for one Sub-system at a time. 
Future Plans : A web based tool would increase speed, 
allow integration across subsystems, more interactions 
with outside information, and allow design solutions to 
be recorded in a database for other HFEAs. 

(21) Lesson : The process of first getting with the LDE to 
understand the subsystem and introducing them to how 
human factors can help their system, then looking at 
documents and drawings, then populating the HFEAT 
with possible requirements, and then following up with 
the LDE to get agreement on the requirements and 
compliance rating worked well. Face to face meetings 
were invaluable in enhancing communications. Phone 
calls and discussions with the LDEs were also helpful. 
Overall the process brought a better HF 
appreciation/understanding to the LDE, and at the 
same time improved the design of the subsystem for 
maintenance, inspections, operations, etc. 

(22) Lesson and Future Plans : A more defined breakdown 
of all the subsystems as a whole would have been 
helpful to see the “big picture” and the boundaries of 
the individual subsystems. At times it was difficult to 
decide what hardware went with which subsystem. 

(23) Lesson : Responsibility of the interfaces between 

subsystems were not always clear. For the most part 
the Subsystem LDE or SE would take responsibility to 
ensure that the interfacing subsystems were meeting 
the human factors concerns of their subsystem. For 
example: lighting, handling and access, KGCS 

(communication connections) Future Plans : A web 
based HFEA Tool/Database would allowed all of the 
Sub-systems to be tracked simultaneously which would 
help the HFE to keep track of the interfaces between 
subsystems. 

(24) Lesson : The use of several HFEs. Because of the 
schedule it was a benefit to have several HFE to keep 
up with the schedule. Also it was benefit to have a 
variety of expertise evaluation the tool and processes. 
Lessons learned were communicated across the team 
during the regular scheduling meetings, and through 
office collaborations. Future Plan : Have separate 
meetings dedicated to sharing HFEA experiences with 
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the tool, and with the results of each analysis. For 
example, peer reviews of the assessments. 

(25) Lesson : Scheduling of assessments should be laid out 
according to the subsystem milestones. There were 
also requests for preliminary reports to be included in 
the data package. Future Plan : A better overall 
approach would be to do a preliminary checklist 
assessment/introduction at the 30% package, a more 
thorough HFEA at the 60% package (several non 
compliances, but they are being tracked by LDE/SE 
and HFE), and a final HFEA assessment at the 90% 
(less non compliances but most have been meet) and 
100% (all non compliance have been resolved) phase. 
Also continual evaluations with the design team at their 
regular meetings is preferred, if the HFE is only able to 
rely on design drawings; sufficient time should be 
allowed for the Subsystem documents to be populated 
in the database before performing the HFEA. Longer 
time frame for the more complex or single assessment 
subsystems (where only a 90% or 100% assessment is 
done). 

(26) Lesson and Future Plan : Although there was human 
factors expertise in L3, there was not adequate 
expertise in L4, Projects (Mobile Launcher, Launch 
Pad, Vertical Integration, etc). At the same time, in the 
early stages there was a lack of resources in L5. This 
delay in HFE resources in L5 required a buildup of 
HFE to perform the HFEAs. There should have been 
integrated communication between human factors 
resources at L3, L4 and L5. As well as better 
integration of a GO HF team (L3, L4, L5) designs with 
Orion Projects, and Ares Projects. See [5] and [6] 

(27) Lesson and Future Plan : Human Factors was not an 
embedded in the SE&I work breakdown structure 
(WBS) in L3, L4, and L5. Although Human Factors 
was embedded in L3 SE&I in the very early stages, it 
soon was relocated into Project Integration, then to 
Integrated Operations. In L4 there were no Human 
Factors POCs. In Level 5 Human Factors was housed 
within Engineering Management and Integrated 
Services. See [7] and [8] about embedding HF into 
SE&I and WBS. 

(28) Future Plan : To improve scheduling, the different 
complexities of the various subsystems could be a way 
to approximate how much time is given to complete an 
assessment. Some subsystems were relatively small 
(few panels, components) and some were very complex 
with interfaces to multiple other subsystems. 

(29) Future Plan : An integrated HFE approach after the 
individual subsystem assessments are completed at the 
60% would be prudent to uncover potential conflicts 
early. And after the 90% assessments are complete for 
all subsystems, an overall, integrated evaluation would 


help tie individual findings back into the “big picture” 
before the 100% . 

(30) Lesson : It was discovered that certain areas of (1) FAA 
were not applicable to launch processing, or that (2) 
other KSC standards already adequately covered the 
same areas as FAA, (3) or that areas were already 
covered by other HFEAs. Future Plan : These aspects 
should be sorted out and incorporated into an improved 
tool, so the HFEA does not use time going through the 
FAA requirements that do not apply to launch 
processing, and also to make sure the human factors 
type requirements in the KSC standards are being 
addressed by the HFE, and so requirements are not 
duplicated across HFEAs. Example; (1) Security type 
requirements in FAA are already covered by KSC 
Security (only the human factors aspects of Security 
should be addressed in HFEA), (2) KSC standards for 
labels, cross connections covered in KSC-STD-Z- 
0006B, etc. need to be tracked by the HFE. (3) the 
Screen Designs for each Subsystem is covered by a 
dedicated HFEA for screen designs for each Subsystem 
through the Integrated Launch Operations Application 
(ILOA) effort, and there is a separate HFEA for 
Kennedy Ground Control Subsystem (KGCS). There 
are many subsystems that interface with the KGCS. 

(31) Lesson : It is important to continually update the HFEA 
schedule as the master Subsystem schedule changes. 
This is important to have good timing with the 
Subsystems. 

(32) Lesson : Post-review of the results would be useful to 
produce lessons learned showing any trends that may 
have been uncovered during the analyses, and applying 
these early to improve the process. For example, it 
was discovered that the area of labeling could use 
some improvement. The need for labels and the proper 
use of labels from past experiences was not well 
documented into the HFEAT. 

(33) Lesson : Have as much information as possible 
prepared prior to beginning the effort. For example, 
during the 30% kickoff meeting with the LDE/SE the 
HFE should have a complete process and products 
defined. The kickoff meeting is mainly to introduce the 
process to the LDE/SE. 

(34) Lesson : The gap requirement flow down from L3 was 
addressed for each Subsystem in the HFEA, some of 
the HFE addressed the gap requirement design issue 
using a less adequate FAA standard. Because qualified 
HFE were performing the HFEA the intent of the 
issues was met through the analysis. Future Plan : For 
requirements tracking reasons, it would have been 
better if the gap requirements were pointed out instead 
of the FAA requirements in some of the HFEA reports. 
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(35) Future Plan : The risk analysis information sheet in the 
HFEAT needs to be updated to include personal injury 
and damage to hardware. 

(36) Lesson : Although the HFEA were deliverables to the 
SDRPs and ERDs, there was a lack of formal 
integration of the FIFE at these meetings for the 
Subsystems. For the most part, HF issues that were not 
easy to resolve were dealt with off line between the 
LDE and SE, not at the SDRP or at ERBs. Although 
this was effective, some of the issues would have been 
resolved earlier and better through formal review at the 
Design Meetings. Thus it was not as effective as it 
would be if HF input was regularly included during the 
Reviews. This process improved for the CCCE HFEA 
for displays. Where for each Subsystem for CCCE at 
the Technical Integration Panels was required to have a 
slide for human factors. Also, the progress for 
requirements development and HFE evaluations was 
tracked through the TIP meetings. Future Plan : Have 
regular HFE input and attendance at all SDRP ERB, 
DR, and TIP meetings. 

(37) Future Plans : Continue applying these processes and 
collaborations to future NASA missions in the 21 st 
Century. Promote more standardized and integrated 
human factors processes and designs between KSC, 
MSFC, and JSC. Ensure that human factors 
engineering analysis remains an important part of the 
Engineering processes. Promote more collaboration 
with the ground support equipment, such as the flight 
and ground interface at the umbilical plates and the 
ground commodity connections to flight hardware. 

(38) Future Plan : Introduce motion capture analysis into the 
tools for human factors engineering analysis, especially 
where a worksite analysis is needed or where two or 
more projects interface where multiple operators are 
required, Ares/Orion/GO [2]. See Figure-3. Motion 
capture allows for quicker and simpler and real to life 
simulations, and the computer models will include the 
CAD flight hardware and human Avatar which the 
envelope spaces between the human and flight 
hardware can be viewed, and the stresses to the human 
can be computed. 



Figure 8 


(39) Future Plan : Incorporate the timeline methodologies 
into the HFEAT [6]. 

(40) Future Plan : See how other FH tools such as the Relex 
HF module can benefit the human factors processes 
within design engineering. Currently the HFEA covers 
several aspects of Relax HF, so it may be possible to 
merge the two somehow into a software tool. 

(41) Future Plan : Develop a Human Factors Engineering 
Plan and Roadmap. 

8. Conclusion 

There were great human factors progress made during this 
era and effort, development of HFEAT, and the HFEAs 
performed on the CxP GOP Subsystems, collaboration 
between CxP L2 to L3-GOP, and L3-GOP to L5 Design 
Engineering Directorate. Now that this has been 
accomplished, these efforts and collaborations will be 
continued and improved as NASA leads the nation and the 
world in future space endeavors and discoveries. 
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